专利摘要:
The present document describes a system and method for determining and assigning a unique identifier for electronic devices such as mobile terminals or smartphones. The method described herein allows the unique identifier for electronic devices to be determined and assigned using a system in the architecture of which is implemented a series of devices called nodes, which act such that same listen to certain bands of radio broadcasts generated by nearby mobiles terminals located in a specific area, to be able to generate said unique identifier from said listenings and, once standardised, propagate the identifier in the system.
公开号:ES2855199A1
申请号:ES202090021
申请日:2017-12-12
公开日:2021-09-23
发明作者:García Isidoro Pérez
申请人:Moxible S L;
IPC主号:
专利说明:

[0002] SYSTEM AND UNIQUE IDENTIFICATION METHOD OF ELECTRONIC DEVICES
[0003] OBJECT OF THE INVENTION
[0005] The object of the invention is framed in the technical field of information technologies and telecommunications.
[0007] More specifically, the object of the invention is directed to the management of association and identification of electronic devices such as terminals in communication networks.
[0009] BACKGROUND OF THE INVENTION
[0011] Today, most of us carry a personal mobile terminal with us all day (hereinafter user terminal, or user terminal for its acronym in English UT), which is present in our life or offline entity (when we visit by various physical sites with the phone in the pocket turned on but not active) and also in our life or online entity (when we visit online sites through web pages or visit mobile applications through said terminal).
[0013] Therefore, in the scope of this solution, we consider that it is the same user who, through a user terminal, uses a mobile application, or uses / visits a web page from this terminal, who visits a physical space with said terminal in his pocket. , although the same person could also use other terminals or devices (desktop computer, Tablet, or similar devices).
[0015] On the other hand, there are currently several methods (among other SMS, instant messaging applications such as whatsapp, email, push from other Apps, Push on the web, etc.) to send a message that makes you wake up (vibrate, sound, screen activation , etc.) to the user's personal mobile device (and most users have it configured this way).
[0016] However, currently we cannot identify that the same user terminal or the same person who is visiting a web page or uses an APP, subsequently visits a specific physical space, and we cannot send a message to the user terminal in the appropriate place with information relevant to your profile (identifying your online and offline activity simultaneously: information on tastes, interests, habits, places you visit, frequency with which you visit, etc).
[0018] In the currently known state of the art for the online identification of UTs and users, in addition to the use of cookies and tracking of IP addresses that present many drawbacks, there are published some methods of "Browser fingerprinting" and "App fingerprinting" that would allow to have of the unique identification of the browser or the APP in the user's terminal, but there are few attempts to identify by proximity in the physical space those same users who can be identified online, especially without the user having to remove the terminal user of the pocket, without having to perform actions to do so every time they go to a physical space, for example when they open an application or the browser looking for a promotion in store, or listen.
[0020] Currently the only systems that combine online and offline detection and identification of UTs focus on the use of very simple hardware such as bluetooth beacon with protocols ( Ibeacon or Eddystone) that are based on including certain functionality within an APP (through an IBeacon SDK ) or in the Browser (if the user configures it with the appropriate permissions) to listen to the unique identifiers emitted by beacon-type devices commonly known in the art by their English name beacon and thus identify different areas of the physical space from the APP .
[0022] The problem is that in addition to the mobile application or activating a special configuration of the browser, the activation of bluetooth is required, and that the phone has a compatible bluetooth model, these conditions must be met simultaneously, which makes the public reach of these systems today it is very restricted. In practice, less than 1% of visitors to a store receive proximity information thanks to this system. On the other hand, although the information that users receive can be linked to online behavior in the APP in the case of the Beacon, there is no relationship with the behavior of that same user when visiting or interacting in the Browser with certain websites as it could be the online store or social networks or digital advertising.
[0023] On the other hand, WiFi tracking techniques based on the detection of the device's MAC address are exclusively designed to identify the UTs in a physical area, that is, for the analysis of offline behavior, without the possibility of linking it to the user's online behavior. For example, they are not intended or allowed in all OSs to communicate push messages to the mobile application when a user terminal is detected in a physical space.
[0025] But nowadays, obtaining a unique identifier from the address of the access layer to the medium of a mobile terminal is currently a problem that is not solved, due to the fact that the operating systems of the current UTs randomize these addresses and the same device can generate dozens of addresses in a short period of time. Most implementations on the market do not overcome this barrier so that when trying to obtain information from devices not associated with a WiFi access point, the quality of real unique visitors that can be identified is very low, since only when the device is connected-associated to the WiFi access points have a unique and offline identifier of the device.
[0027] Another well-known problem is having a unique identifier of the user terminal and the user in offline and online, both for Android and for OS, it is another problem that is not solved, since from some widely used operating systems (such as ¡ OS 10), it is not allowed through an APP (including the Browser) access via software to the permanent identifiers of the device, such as the MAC address or address of access to the medium of your network cards. In the case of the application, the online advertising identifier of the user terminal could be accessed, but the web browser in turn does not have access to the advertising identifier, and on the other hand when the phone is not in use (that is, it is offline) the online advertising identifier is not issued or shared in any way, so it cannot be used to cross it with the offline detection of the address of access to the medium of your network cards.
[0029] It is therefore necessary to have the possibility of carrying out a unique identification of electronic devices, such as user terminals, offline and online that also allows distinguishing and analyzing offline behavior not only people, but also things, for example a location of your assets.
[0030] DESCRIPTION OF THE INVENTION
[0031] Throughout this document, the following terminology is used:
[0033] - The term system to describe any number of components, elements, subsystems, devices, packet-switched elements, packet switches, access switches, routers, networks, computer and / or communication devices or mechanisms, or combinations of components thereof. The term computer includes a processor, memory and buses capable of executing an instruction in which the computer refers to one or a group of computers, personal computers, workstations, mainframes or combinations of computers thereof, such as a network. . Likewise, users must be understood as any natural person or any software or physical system / machine / robot that accesses or is present in any type of:
[0034] a) online space, that is, it maintains an active / open connection / session through any type of communication network or uses / interacts with online information services such as web pages or applications (in this document also referred to as APPs) or networks social).
[0035] b) offline space (stores, cities, shopping centers, airports, etc.), that is, when being present in the physical space they do not maintain an active communication / session or are interacting online, although they have a terminal (equipment with capabilities information processing and communications) that allows them to go online at any time.
[0037] - NS Server Node: It acts as a device of a centralized architecture for the storage, processing and distribution of information to the rest of the elements.
[0039] - Signatures: Succession or array of hashed (encoded) fingerprints generated by the same device, according to the IEs and / or SSIDs received, according to the capabilities via APP or via WEB. Each signature has a position, the first ones are called base signatures, and they are obtained when their deviceID has been homologated and validated, the rest are additional signatures that will add value as a whole.
[0041] - Visitor: person or any type of device (things machines, robots
[0042] - physical or software) different from others that access a space (physical or digital) generating events in said space.
[0043] - Visit, continuous short presence considered by the continuous grouping of events of a visitor in a physical or digital space.
[0045] - Visit, grouped presence of a visitor in a period considering the discontinuous grouping of events of a visitor in a physical or digital space.
[0047] - Users any type of natural person or thing / machine / robot software or physical that access or are present in any type of online space ( website, applications, social networks) or physical (among other travelers of transport systems, citizens, tourists , shoppers in stores, and any type of person in any type of physical space) who have a device with information processing and communications capabilities.
[0049] - User terminal, any device carried by a person, usually active / robot in his offline life, and which is also used as a device for personal access to online media ( website, applications, services, queries, internet, etc ... communications telephone, voice, audio, data, etc ...) that supports multiple applications, sensors, actuators, displays, buttons, keyboards, etc. User terminals can be personal or non-personal. Personal devices can do all their functions even if they are not under human control, that is, when they are at rest or not active. But it is considered personal since its physical entity is still linked to the natural person.
[0051] The object of the invention is based on the daily use of mobile devices that we use in our day to day (smartphone, tablets, smart watches) that act as an interface between our offline life (when we move to various physical places with the phone in the pocket) and our online life (when we move around visiting web pages or use mobile applications).
[0053] Unlike the use of simple beacon- type transmitter systems installed in the physical space, together with mobile applications that install and authorize users to listen to beacons, the invention described below is based on an intelligent device, which we will call Node, mainly dedicated to listening and processing radio information from the UTs.
[0054] By locating this intelligent Node device in a physical space, it will receive and demodulate and decode the signals in the public frequency bands (2.4 -3.6 and 5Ghz) in which other mobile terminals broadcast frequently due to communication protocols. radio they use (WiFi, Bluetooth, others), so by analyzing the received frames you can detect the presence of mobile devices in a physical area (offline space) anonymously without any intervention.
[0056] In collaboration with the functionality designed in the form of a kit for developers (Software Development Kit, SDK) usable in current operating systems (OS, Android, ...) and also for HTML5, an identifier system is built that we will call hereafter Offline Online Identifier (OOID) to achieve a high probability of uniquely identifying the user terminal in a unique way both offline and online, which hereinafter we will call Homologated OOID.
[0058] Various mechanisms are designed to propagate and update the information contained in the OOID to the different elements of the architecture (Node, APPs, Browsers, Server). Said OOID will persist and will be updated in the user terminal also when the user terminal is turned on but not used (offline).
[0060] Said device and methods are applied not only to the generation of OOID identifiers, but also to achieve the sending of messages by multichannel proximity, achieving a high number of UTs that, without any gesture from the user, receive information associated with their profile in their user terminal. by proximity in physical areas (provided they have been legally authorized).
[0062] Mechanisms are designed that allow, in a transparent way to the user, when the user terminal passes near the Node, a communication is established between the two, for the exchange of OOID information or the direct sending of messages to the user terminal.
[0064] Methods are designed to maximize the number of UTs that are uniquely identified in the physical space by proximity even if they use random MAC addresses or Virtual MAC addresses, with the aim of being able to improve the unique identification of their cross online and offline behavior and to be able to send message by proximity to more UTs. In practice, with respect to the 1% of total visitors to uniquely detected devices that are achieved using bluetooth beacons or the 20% that can be detected using WiFi beacons, are achieved with implementations of the object of the invention and associated systems rates of between 60 to 80%.
[0066] The device and associated components make it possible to have a system with many industrial applications today, thanks to having an OOID, especially useful in the field of marketing. In general, in these marketing applications, it is not necessary to guarantee 100% the unique identification of the UTs at all times and in all environments, but only to try to communicate with the maximum number of people possible in the appropriate place and time, with messages. relevant to the consumer that can be chosen by analyzing their behavior in various media or channels.
[0068] The anonymous online and offline behavioral information that the system collects is anonymous, the identification of the person who carries it is impossible, but with the user's consent it can be linked to personal or other information provided by the user or available in other systems ( CRM, POS, etc.), the design includes a new profiling system that allows incorporating personal and non-personal information (psycho-socio-demographic, and transactional) mixed anonymous behavioral information online and offline (in App, Web and physical location) obtained 24/7 and in real time.
[0070] DESCRIPTION OF THE DRAWINGS
[0072] To complement the description that is being made and in order to help a better understanding of the characteristics of the invention, according to a preferred example of a practical embodiment thereof, a set of drawings is attached as an integral part of said description. where, with an illustrative and non-limiting nature, the following has been represented:
[0074] Figure 1.- Shows a diagram showing a possible architecture model and the enumeration of the elements considered and the direction of the main flows of messages or information between them.
[0076] Figure 2.- Shows an example of an event table where the structure and functions required in the events between elements of the system are detailed.
[0077] Figure 3.- Shows an implementation of 001D in which the structure and necessary functions in the online and offline identifier are detailed.
[0079] Figure 4.- Shows a diagram showing the processes for verifying the OOID.
[0081] Figure 5.- Shows a diagram showing the processes dedicated to the propagation of the OOID.
[0083] Figure 6.1.- Shows a descriptive table of the Node Device.
[0085] Figure 6.2.- Shows a diagram of the direct node notifications system
[0087] Figure 7.- Shows a table in which the main functions of the APP SDK are appreciated.
[0089] Figure 8.- Shows a table in which the main functions of the WEB SDK are appreciated.
[0091] Figure 9.1.- Shows a table showing the main Server Node or Server functions.
[0093] Figure 9.2.- Shows a diagram where the behavior analysis works, detailing the online and offline behavior management module.
[0095] Figure 9.3.- Shows a diagram where the parameters of the calculation of visitors, visits and visits are appreciated, describing the techniques for analyzing online and offline behavior.
[0097] Figure 9.4.- Shows a diagram showing the interaction between systems, detailing the operations between modules and subsystems.
[0099] PREFERRED EMBODIMENT OF THE INVENTION
[0101] In a possible preferred embodiment of the object of the invention, it is required to have unique identifiers that allow crossing the information on offline and online behavior, using the following elements that are described in the architecture of Figure 1.
[0102] In different alternative embodiments, configurations of the architecture described below could be varied, and that has been considered as the best alternative in the current state of technology, thinking of using a central element or server and a large number of low-cost devices ( nodes) forming an extensive network, although a model where the server functions are distributed in the nodes could also be used, having a distributed network scenario.
[0104] In this preferred embodiment, the elements that are combined in the architecture are:
[0105] - An intelligent hardware device or Node (101), comprising, among others, a radio frequency listening module.
[0106] - A series of electronic devices (102) such as user terminal equipment (102), referred to in parts of this document as UTs (102), capable of executing mobile applications where an APP SDK (104) is integrated for mobile applications or APPs , and where a web browser runs that in turn have an integrated web SDK (105) preferably under HTML5 for web pages.
[0107] - NS or Server Node (103) with subsystems or modules - preferably implemented in hardware software - for analysis and propagation of online and offline identifiers (106), behavior management module (107) offline and online and a campaign manager module that includes a module for analyzing profiles and results (108), all with different connections between them. The Server Node (103) acts as a centralizer.
[0109] - NS or Server Node (103) preferably implemented in hardware, which includes among other subsystems or modules-:
[0111] a) software- analysis and propagation of identifiers online and offline (106)
[0113] b) behavior management module (107) offline and online
[0115] c) a campaign manager module that includes a profile and results analysis module (108), all with different connections between them.
[0117] - The Server Node (103) acts as a centralizer.
[0118] Through the behavior analysis module (107) it is possible to obtain information on offline detections (node events), which are analyzed to calculate visitors, visits and visits, and updates data from an Online Offline Identifier, called OOID for its acronym in English, to the rest of the elements.
[0120] Through the behavior analysis module (107) information (SDK events) is obtained from the online use of mobile applications of the SDK APP (104) and browsers visiting web pages through the WEB SDK (105) in order to perform a behavior analysis online cross in the module of analysis of profiles and results (108).
[0122] Through the results and profiles analysis module (108), cross- offline and online behavior profiles are generated, and the results of communication campaigns are analyzed, updating profiles and the OOID identifiers of the UTs (102).
[0124] Through the campaign module, information is exchanged between the various elements of the architecture to send a push message through the various possible channels enabled to the user terminal (102) of the user.
[0126] On the other hand, a communication subsystem based on events (frames or discrete pieces of information) is designed from the UTs (102) and Node / s (101) to a server (SETS, Send Events to Server) and a communication protocol from the server to the Node and UTs (REFS: Receive Elements from Server).
[0128] In various implementations, for any communication between the elements of the architecture, Node events (those that travel between the Node (101) and the server node (103) or SDK events (those that travel between the SDKs and the server node) could be used. (103), with the following elements among others:
[0130] - Timestamp, universal timestamp of the moment of the APP_ID event, identification of a digital application or physical space.
[0131] - Node_ID, identification of a node or a physical zone.
[0132] - Geoloc, coordinates and geolocation precision.
[0133] - Type event or information that is sent and its specific parameters.
[0134] - MoreInfo, you can use it to send more information on maintenance, sending lists, objects, etc.
[0135] The OOID identifier can include, among others, the elements that can be seen in figure 3. In this way, there is a Device Identifier (dID), which can be generated from a SHA1 Hash at runtime of the address of the layer of access to the medium (whether or not it is random) that can be obtained in the frames listened to from the Node (101), or via software in certain versions of the OS of the UTs (102).
[0137] Although the rest of the elements present in figure 3 and that are described below were not included, the dID would always be present in the OOID even with a random, non-homologated value, in turn the dID could be updated by the process of OOID propagation by the SDKs (104, 105), the server node (103) or the Node (101) as soon as the certified OOID is known.
[0139] As can be seen from Figure 3, the OOID can comprise an OUI, which corresponds to the first three bytes of the address of the media access layer of the user terminal (102) and will be used in the homologation process of the OOID.
[0141] The object of the invention contemplates the implantation of a succession of signatures that we call by its term in English arrayo in Spanish succession of signatures, which allow adding signatures to it, understood these signatures as characteristics of the user terminal (102) or of its behavior, which can be obtained and propagated by Nodes (101), Server Node (103), APP SDK (104) and WEB SDK (105) in combination. That is, they are obtained by combining online and offline information sources.
[0143] The object of the invention makes use of processes of homologation, unification, acceptance and propagation of OOIDs. In some implementations, the following processes could be carried out in any of the architecture components that receive events with OOIDs from UTs (102), especially in the Server Node (103); For this, in the homologation, those OOIDs that by any method have been verified that their dID comes from a real and non-random address of the middle access layer of the user terminal (102) can be marked with the Homologated status. They are used to determine the number of unique visitors and to have unique identification in the message delivery system.
[0145] In some implementations, Homologated OOIDs can be obtained directly:
[0146] - By offline detection of the Node from the address of the access layer to the real medium of the frames heard both when the device is discovering frames and when it is associated with an access point, hereinafter AP.
[0147] - By detection of the Node (101) when the browser connects a UT (102) to a captive portal of the Node (101).
[0148] - In the SDK APP (104) Android by software from the address of the layer of access to the medium.
[0149] - In the SDK APP (104) ¡OS up to ¡OS9 by software from the address of the media access layer.
[0150] - In the SDK APP (104) ¡OS by software when the Smartphone has WiFi connectivity up to 10.3 from the address of the medium access layer.
[0151] - As of OS 10.3, different techniques are combined, such as the direct connection to the AP-AP hidden from the Node by Proximity or the propagation of the OOID between the different elements of the architecture.
[0153] In a possible alternative embodiment, the OOID could be homologated by generating the dID in the SDKs (104, 105) and Nodes, or later in the Server Node only with the OUI without the need to store or send the full real address to the server node (103) (for privacy), for this it could be contrasted against the list of OUIs of official manufacturers, against a history of real OUIs (used by Chinese manufacturers that do not use the official list) available before the randomization processes existed, and against a list of virtual or false OUIs, which have been detected as such, since they appear with an unnatural behavior, even at night, and verified with the different models of UTs (102) in different locations.
[0155] In the unification, the Unified status of a non-approved OOID can be marked when there is a high degree of coincidence or a small distance between the set of signatures with another Approved OOID (which has been received through the propagation process. You can create a record of unified OOIDs between them that would be used among other tasks to determine the number of unique visitors and visits in the offline behavior analysis process. When a device is unified, among other processes, the matching signatures could be added between the Approved OOID and non-approved OOID, thus propagating a unified OOID in signatures. In this unification process, repeated or contained signatures could be eliminated to optimize the process. And they could be ordered so that the coincidence measurement could be implemented agilely in the case of many signatures, assigning a greater weight to the first signatures that allow a better unique identification of a user terminal (102).
[0157] One could measure the distance between two signatures of two OOID (A and B), and the
[0158] match between signatures of the OOIDs according to the following formulas:
[0159] Distance D = ( fi rm to A - fi rm to B x signature weight)
[0161] where the signature weight is a configurable value that can be modified to give a fine adjustment to the system. And the coincidence between the set of signatures of each OOID, as the sum of the distances of the signatures compared one by one for those existing between both OOIDs,
[0163] Match C = Sum i = 1 ; i = n {D ( i)}
[0165] Where n is the number of matching signatures available between both OOIDs.
[0167] For acceptance, the Accepted status of a non-homologated and non-unified OOID can be marked when there is a medium degree of coincidence between the set of signatures with another Homologated OOID. Likewise, a record of unified OOIDs could be created between them that could be used in the behavior system to determine the time of presence and the number of visits. In this case, neither signature concatenation nor propagation would have to occur. A unified OOID record could also be created between them.
[0169] For validation, the Validated bit can be marked (and therefore could be used for analysis and other processes) of those OOIDs that are not excluded from it for different reasons, among others:
[0170] - Because they are blacklisted (Robinson).
[0171] - Because they have been excluded by other valid data verification methods, such as:
[0173] o They appear simultaneously in two very distant locations,
[0175] o They do not have enough detections with power variations that imply a certain movement within a space with several nodes (101), that is, their behavior is similar to fixed devices.
[0177] A part of the method object of the invention is based on the online and offline identification from the propagation of the OOID obtained for the UTs (102), by various means (such as events or silent push notifications) and is applied, not only to the server node (103) but to all the elements of the architecture, implementing at least the functions shown in figure 5.
[0179] In this way, it is necessary to When an OOID is received, it is compared with the available OOIDs, being updated if necessary according to the homologation, unification, acceptance and validation methods. Normally the SDKs (104,105) that run the UTs (102), have information only about their OOID, but the server node (103) will receive at some point all the OOIDs generated in the system, the nodes (101) could receive information from all the OOIDs or only part of them (those that are in the same NodeID zone or APPID application).
[0181] The server node (103) can broadcast the homologated OOIDs to other applications and browsers, mini-browsers (which are launched automatically in some UTs operating systems (102) when a captive portal is accessed) and embedded browsers ( webviews) through various techniques among others:
[0182] - Through silent push (actively).
[0183] - Through SDK functions every time a computer is started or run
[0184] - APP process.
[0185] - Using SDK functions every time you connect to a page with HTML5 SDK
[0187] In this way, the propagation process guarantees the propagation of Homologated OOIDs:
[0188] - Received from a WebViewBrowser that in turn has obtained it:
[0190] o When opened by an APP
[0192] o From a shared cookie.
[0193] - Received from the Browser that in turn has obtained it:
[0195] o Updated by the server node (103).
[0197] o Updated by the Captive Portal of the Node (101).
[0198] - Received from the server, which in turn has obtained it from:
[0200] o Another App that has previously obtained it from:
[0201] ■ The MiniBrowser, Browser with Connection to a Captive Node Portal (101)
[0202] ■ The WebViewBrowser.
[0203] When propagating an OOID, the number of the propagation status can be encoded, to know if it has been diffused several times to all the elements of the architecture. Only homologated / unified and validated OOIDs are propagated, updating in real time. The server node (103) can update the status of the OOIDs that are not Homologated to Homologated and also update their value in the historical data associated with UTs (102), or only store the historical relationship between OOIDs from the date of homologation without altering the OOIDs of past data.
[0205] In this way, there is a system whose architecture and configuration allows the above actions to be carried out in order to implement, in a possible embodiment thereof, the method object of the invention. Said architecture corresponding to a preferred embodiment of the object of the invention comprises the Node device (101), which responds to a structure such as that shown in figure 6.1 and which according to implementations may include, among others, the following functionalities labeled in said figure 6.1, having in this way the following functionalities:
[0207] - SETS: Listen and process frames emitted by the UTs (102) both when they are and when they are not associated with wireless networks that make use of WiFi, that is to say, WLAN type. From the information of said frames, they could generate an OOID at runtime, process it, among others, with the homologation, unification, acceptance and validation systems described above, and generate one or more Node (101) events. They could listen to and process frames emitted by the UTs (102) when they have bluetooth (BT) communications. From the information of said frames, they can generate an OOID at runtime, process it among others with the homologation, unification, acceptance and validation systems described above, and generate one or more Node (101) events. Among other mechanisms, it is considered to establish a virtual private network (referred to in this document as VPN for its acronym in English) with the server that guarantees the privacy of the information between both. The Node events generated can be stored until the connection with the server is available.] To save computation in the behavioral systems, it is planned to be able to group the data of the detected frames or detections made during a small window of time and send them in a single Node event, which contains, in addition to the OOID, only the information on the number of detections and the average detection power. Therefore the events could contain information from a single detection or several in a short space of time. Additionally, in each node event, it could include among other data more useful information for remote maintenance (such as its IP address, GPS coordinates, list of nearby SSiDs).
[0208] - REFS Node: Among other information, it could receive in real time from the server, information on approved OOIDs, for the execution of the unification process. Among other information to support all the functionality of the system, it could receive in real time from the server, information on events from other Nodes (101), OOIDs of UTs (102) that enter the Geofence Virtual Node with their SSIDs, campaigns, profiles, tokens for communication with the user terminals (102), the list of manufacturer OUIs, a history of OUIs available before the randomization processes existed, a list of virtual or false OUIs and the list of validated OUIs.
[0209] - Hidden access point NODE: A hidden access point (AP) can be generated only known by the UTs (102) where the APP SDK (104) has been integrated, allowing WLAN connections with said UTs (102). Likewise, it can generate a BT point visible mode to pair with other user terminals (102) that know a link number (PIN) only available in the UTs (102) where the APP SDK (104) has been integrated, allowing BT connections with said UTs (102). In some implementations, it could be through a socket and, among other information, it could send its Homologated OOID to the connected UTs (102), since it would have enough information in the level 2 connection to Homologate the OOID. Being able to disconnect them once confirmation is received that all the information has been correctly received in the UT (102) to be effective in the number of user terminals (102) connected simultaneously.
[0211] A Captive Portal Node is responsible for generating an access point, an AP, visible in open mode with a captive portal, to allow connections with any user who wishes (for example, because he is trying to register in a loyalty program, validate a coupon received by email, or because you are looking for free internet access). By means of dynamic modification techniques of the DNS of the node (101) or others of the captive portal, it could always redirect it to the browser of the user terminal UT (102) to the same domain (the one associated with the NS web server for example) thus loading the web page main captive portal of the Node that would include the WEB SDK (105). In this way, Node (101) would identify and access the frames sent for connection to the captive portal, It could, among other methods, homologate the OOID and through the WEB SDK (105) store it on a local storage device that we call by its English name localstorage or in the form of cookies associated with said default domain.
[0213] An unauthorized Rogue type node that we define Rogue Node can be in charge of generating WLAN beacon frames to announce an available SSID and force nearby user terminals (102) to send association frames if they have said SSID in their list of connected networks . Among other sources, the list of SSIDs to be announced could come from the one received from the server and previously obtained by the SDKs installed in the UTs APPs, from the most popular SSIDs but not detected in the vicinity by the Rogue Node (since these already are announced) or the history of SSIDs announced in the WLAN discovery frames of the UTs that are included in the signatures of the OOIDs exchanged with the Serving Node (103) (coming from other nodes). The mechanism to prioritize, optimize and trigger the announcement of SSIDs could be, among others, to announce first and periodically, until receiving the response from the user terminal (102) within a configurable period of time, those SSIDs from the SDK APP (104) of UTs (102) known by geolocation (which we can call Virtual Node) have entered some coordinates within a configurable radius around the Node (for example 0.5km).
[0215] A Beacon Node can be in charge of emitting frames by bluetooth according to the ¡Beacon ™ and EddyStone ™ protocols that through an APP or the Browser could be detected and through the APP SDK (104) and could generate a Node event (although it has not been generated by the node but by the UT (102) with the information of the Homologated OOID if it were known by the UT (102).
[0217] Optionally, a direct Push node can be used that allows including a campaign manager within the node itself (101), avoiding delays in sending messages from the server, and making the node (101) itself the that manages the sending of messages to the user terminal (102), or even when it has direct communication with the user terminal (102) by proximity through the system designed for this purpose, it can call direct functions of the SDK (104, 105) to show the user the message directly (through among other techniques such as local push notifications, PopUps, etc.) without having to use the available channels of the user terminal (SMS, Push, Email, ...) . The Node would receive to the Server Node (103) the tokens of the approved OOIDs as well as any other information related to the campaigns.
[0218] It could use, among other techniques, offering through the HotSpot2.0 protocol to provide a communication channel and that the UTs (102) use this channel to ask an AP for network access information using the ANQP ( Access Network Query Protocol). ) with its address of the access layer to the real medium, thus increasing the probability of obtaining the homologated OOID in less time for those devices that randomize it. It could use among other techniques to increase the probability of obtaining the homologated OOID in less time for those devices that randomize the address of the media access layer, HotSpot 2.0 HS2.0 to provide a communication channel and that the UTs (102) use this channel to ask an AP for network access information using the ANQP ( Access Network Query Protocol) offering its address of the access layer to the real medium. In this way, it could be used, among other techniques, to announce frames of the protocol used to facilitate pairing between devices called Wi-Fi Protected Setup (WPS), to force the UTs (102) to generate a UUID identifier, which will be collected as one more signature that will help to unify the UTs (102) that randomize the address of the access layer to the real medium.
[0220] To increase privacy in locating and identifying the UTs (102) that are in the physical scope of the Node (101) among other mechanisms, the node (101) can generate real-time or execution frames of discovery of the WLAN or BT networks, which are normally broadcast by the UTs (102), using the same addresses of the media access layer of the UTs (102) recently listened to, or those listened to by other nodes and that have been received by the propagation process, and also generate them randomly with different common patterns similar to those usually received.
[0222] Likewise, it is contemplated to be able to perform the analysis of SSIDs received in the discovery frames, among others, generating a signature for each SSID-S detected, which can be concatenated to obtain greater efficiency in the process of unification of OOIDs. I can perform the analysis of the Information Elements (IEs) contained in the WLAN frames such as Supported Rates, High Throughput capabilities, Interworking Capabilities, and WPS or Wi-Fi Protected Setup, we can have a high number of unified devices to certain models, and provide the signature basis for the rest of the models. Specifically, through the IEs signature, we can distinguish if it is an ¡OS8 or higher device, which helps to optimize Unification, Acceptance and Validation processes.
[0223] The possibility of performing the analysis of the shuffled and predictive seeds of the radii themselves used by the UTs (102) to detect coincidences is also contemplated.
[0225] In those implementations where the SDK APP (104) is used, the functionalities of the SDKAPP (104) are used that are shown in figure 7 and that respond to:
[0227] SETS:
[0228] They could generate an OOID from the information available via software, and among other moments every time the application or APP is started or before closing or when there is any user interaction, SDK APP events could be generated (104) towards the Server Node (103). To obtain the approved OOID, the APP SDK (104) could access the address of the middle access layer of the user terminal (102) and if it is not accessible, a random dID and non-approved OOIDs would be generated. Upon receiving information from the Server Node (103), the OOID is updated with the OOID approved in localstorage, cookies or other means to ensure the persistence of the information accessible to the SDKAPP (104).
[0230] Object and usage tracking:
[0231] To learn more about tastes, interests, etc. Functions that the programmer could use in his APP are incorporated to monitor the behavior of objects and the use of the same APP by the user through signatures obtained from:
[0232] - Session Events SESSION-S, each time the user opens the APP, the number of sessions carried out by the APP in that user terminal could be increased by one (102).
[0233] - Click events CLICK-S, each time the user clicks, it could accumulate the number of clicks on each object to be analyzed in a period
[0234] - Text events TEXT-S, each time the user writes in a field or the programmer passes an alphanumeric character parameter (for example the points accumulated in the game or loyalty program or the opening or closing of the application).
[0235] - ECOMM-S electronic transaction events, similar to text events but with specific parameters that identify the purchase orders in electronic stores.
[0236] - Events of visual printing of IMPR-S objects, where the total time and number of times that an object has been visible on the screen of the user terminal (102) is collected, taking into account the space on the screen.
[0237] - NAVI-S Navigation Events, which collect the navigation depth indicating whether it has passed through several sections of the APP before.
[0238] - MDIA-S multimedia events, which collect the activity settings with players, for example if you have finished watching the video.
[0240] Tokens and personal data:
[0241] Among other data, those data - personal or non-personal - that have been provided by the user and collected through the behavior and interaction monitoring functionality available, can be sent to the Server Node, which can serve as communication tokens ( that is, identifiers in a communication system) among other data such as telephone number or email, or social login that could serve as tokens for sending messages.
[0243] Rogue
[0244] Among other data, it could send to the Server Node (103) the SSIDs with which the user terminal (102) has connected that will arrive at the Node (101).
[0246] REFS:
[0247] Among other data, it is possible to receive in real time from the Server Node (103), information on the definition of geolimited areas or geofence by name in English, information on campaigns such as their elements and objects, the list of manufacturers OUIs, a history of OUIs available before the randomization processes existed, and a list of virtual or fake OUIs, the list of validated OUIs. When receiving external push notifications, it could manage the collection of notification parameters, so that automatically according to the campaign schedule it could open embedded browsers in the APP or external browsers.
[0249] Geofence :
[0250] A Node type event can be generated (as if a node had been detected by proximity), to have a virtual Node at any physical point, and to activate the Rogue Node functionality in the Node (101).
[0251] They questioned:
[0252] It can be connected to the hidden AP access point of the nodes or to the BT connection offered by them, and through socket or other communication procedures exchange its approved OOID among other data. It will be in the process of installing the APP that the user would be asked for the appropriate permissions for the direct connection to the hidden AP of the nodes or even the installation of a profile for this purpose if necessary in some models of ETs operating systems.
[0254] Spread:
[0255] Among other times, every time it knows its approved OOID, it can be propagated to the server Node (103) as well as to the UT browsers (102), for which it could use the following methods, among other methods:
[0257] - Open a browser embedded in the APP (e.g. WebView) and pass the approved OOID as parameters in the URL.
[0258] - Open an external browser configured by default in the user terminal and pass the approved OOID as parameters in the URL.
[0260] Direct PUSH:
[0261] Through an internal campaign manager such as the one described above, the list of campaigns and objects received can be frequently analyzed to launch a Local Push Notification, avoiding the need for you to have any internet connection to receive push messages at the time scheduled in the Bell.
[0263] INTERNAL_AP:
[0264] In those UTs (102) that your OS / operating system allows it (with the appropriate user permissions) it could generate a hidden AP, while the UT (102) does not use the WLAN connection, to which any other UT can connect (102 ) -even the same obtaining the Approved SUID of the UT (102) in a totally analogous way to how it is done in the node (101) by this means.
[0266] In the process of installing the SDK APP (104), the user will accept the conditions of use and give all the appropriate permissions or even install the necessary use profiles, for each of the functionalities that have been described above, ensuring compliance with legislation on this matter.
[0267] Privacy and permissions:
[0268] In the process of installing the APP application with the integrated APP SDK (104), it is the user who authorizes all the permissions and accepts the conditions of use that derive from all the functions mentioned above.
[0270] Firms:
[0271] The possibility of using capacities or other identifiers obtained from the APP via APIs of the OS is established, such as, among others, IDFA / GAID, Carrier, Screen resolution and color depth, Model, Memory, installed Apps to generate other signatures. Specifically, the IDFA / GAID signature could be generated, since this is a unique identifier per device accessible only via software from a mobile application. All mobile applications on the same device have the same GAID / IDFA provided by the manufacturer, for advertising use. Likewise, they could be used, among others, Gender, Date of Birth or Postal Code provided by the user directly in the interaction with the APP, to generate a signature based on personal data PUS (Signature of Personally Identifiable Information). Said information will be supplied and processed by the system in accordance with current legislation. That is, for example, these signatures will not be generated without the user's prior informed consent, and they may be removed.
[0273] It is also expected to use other non-personal data provided by the user directly in the interaction with the APP, to generate a signature based on non-personal data NPIS (Non-Personal Information Signature). Said information will be supplied and processed by the system in accordance with current legislation.
[0275] In those implementations in which the WEB SDK (105) is used, it has to be influenced by the functionalities that are seen in figure 8 and that correspond to:
[0277] SETS:
[0278] Among other moments, every time you load the website with the HTML5 SDK or before closing said page, it could generate SDK events that will be sent to the Node through calls to NS functions (for example, Php functions or other application platforms). Server). When receiving information or when being launched from an APP, update its OOID, stored in localstorage, cookies or other means to ensure the persistence of the information accessible to the SDK. When connecting to the Captive Portal of the node (101), updates the 001D stored in localstorage or in cookies or other means to ensure the persistence of the information accessible to the SDKWEB (105).
[0280] Object tracking functions:
[0281] To learn more about tastes, interests, etc. Functions that the programmer could use in their HTML code can be incorporated to monitor the behavior of objects and the user's own use of the site or WEB application through signatures obtained from:
[0282] - Session Events SESSION-S, each time the user opens the WEB application, the number of sessions carried out by the WEB application in that user terminal could be increased by one (102).
[0283] - Click events CLICK-S, each time the user clicks, it could - accumulate the number of clicks on each object to be analyzed in a period.
[0284] - Text events TEXT-S, each time the user writes in a field or the programmer passes an alphanumeric character parameter (for example the points accumulated in the game or loyalty program or the opening or closing of the application).
[0285] - ECOMM-S electronic transaction events, similar to text events but with specific parameters that identify order orders in electronic stores.
[0286] - Events of visual printing of IMPR-S objects, where the total time and number of times that an object has been visible on the screen of the user terminal (102) is collected, taking into account the space on the screen.
[0287] - NAVI-S Navigation Events, which collect the depth of navigation indicating whether it has passed through various sections of the site or WEB application before.
[0288] - MDIA-S multimedia events, which collect the configuration activity with players, for example if you have finished watching a video, etc.
[0290] Tokens and personal data:
[0291] Among other data, it could send to the Server Node (103) those personal or non-personal data that have been provided by the user and collected through the behavior and interaction monitoring functionality available, among other data such as telephone number or email. , or access data to social networks that can serve as tokens for sending messages to UTs (102).
[0292] PUSH Web:
[0293] To implement so-called web push notifications, upon receiving the
[0294] Web SDK (105) an NS event in real time via AJAX or any other web protocol for sending asynchronous events, could open other windows (pop-up) or dynamically change the content of a banner on the web page where it is integrated or any other action that the programmer wishes to integrate into the web page.
[0296] Browser notifications:
[0297] It is expected to use the browser's own notification system (depending on the type of browser open) if it has the appropriate permissions.
[0299] Firms:
[0300] A WEB-S signature can be obtained in the form of an array of signatures in turn from collecting information from the user terminal itself (102) according to the capabilities obtained from WEB, such as UserAgent, http accept header, or the resolution of screen and color depth among others. Among other things, Gender, Date of Birth or Postal Code provided by the user could be used directly in the interaction with the WEB site that are collected through the object tracking functions of the web SDK (105), to generate a signature based on data. Personal PII-S (Signature of Personally Identifiable Information). Said information will be supplied and processed by the system in accordance with current legislation. That is, for example, these signatures are not generated without the user's prior informed consent. Other non-personal data provided by the user directly in the interaction with the website may be used to generate a signature based on non-personal data NPI-S (Non-Personal Information Signature). Said information will be supplied and processed by the system in accordance with current legislation.
[0302] Spread:
[0304] Among other moments when the user launches the browser of the user terminal (102), each time he accesses a WEB site or application, the WEB SDK (105) could be loaded and through techniques of passing parameters in the URL or other techniques , the Homologated OOID would be exchanged with the NS. The OOI is saved in the browser's localstorage or in cookies if possible, among other methods. Also when the embedded browser (WebView type) is launched from an APP with the APP SDK (104), the approved OOID is exchanged with the APP. The OOI is saved in the browser's localstorage or in cookies if possible, between other methods. Similarly, when the external browser configured by default in the user terminal (102) is launched and the approved OOID is passed to it as parameters in the URL. The OOI is saved in the browser's localstorage or in cookies if possible, among other methods.
[0306] The server node (103), whose main functions can be seen in figure 9.1, has the following functionalities:
[0308] SETS:
[0309] It is possible to receive, store and process the events of the SDKs (104, 105) and nodes (101), using web servers, databases and / or applications.
[0311] REFS:
[0312] It allows sending and responding to requests for information from the SDKs (104,105) and the Nodes with data, among others, of SSIDs, tokens, profiles, campaigns and results, the list of manufacturers OUIs, a history of OUIs available before the existence of the randomization processes, and a list of virtual or fake OUIs, the lists of validated OUIs.
[0314] ROGUE:
[0315] You can receive the list of SSIDs to which a UT (102) connects through the SDK APPs (104). You can also broadcast the SSID list received from the SDKs (104,105) to the Nodes
[0316] ( 101 ).
[0318] Firms:
[0319] From the combination of the identifiers of events, campaigns and responses or results, it could create a different OOBS signature for each combination of information sent to the user terminal (102) by messages in any place or in a specific place and subsequent detections made by the Node (101); For example, if a user terminal (102) is detected in an area B that was in an area A which, within the programmed period of the campaign, has been invited by means of a message to move to area B.
[0321] The object of the invention may be of interest in behavioral studies or user interaction analysis applications. For this, the object of the invention can have a behavior analysis system as detailed in figure 9.2. Said system behavior analysis has a series of functionalities that allow that, from the events of Node (101) and from the SDKs (104,105) in the server node (103), visitors, visits and visits are calculated or computed [9301] , as well as any other indicator or ratio that is considered of interest from these to obtain the cross behavior online and offline of the UTs.
[0323] Likewise, it is foreseen to submit these events to the processes of Homologation, Unification, Acceptance and Validation and Propagation described above.
[0325] Normally the nodes (101) generate events of type Node and the SDKs (104,105) of type SDK; but the SDKs (104,105) could generate node type events, when the detection is done by beacon. The nodes (101) could generate SDK-type events when the detection is made when connecting to a captive portal (an SDK-type event is generated) this information will be treated by the behavioral system as if it came from the type of event received.
[0327] To carry out a calculation of visitors, visits and visits it is in a physical site (physical area of scope of the Node (101)) or an online site (App or Web where the SDK APP (104) or in the SDK ( 105)) totally analogous methods are used. In different implementations, models similar to the one shown in figure 9.3 can be implemented. to get to get visitors, or visits.
[0329] Each time an event is received at the Server Node (103), it is registered and can be analyzed taking into account the information of previous events available, during a period of time. Subsequently, different indicators can be obtained for different time periods such as hours, daily, weekly, monthly, yearly, etc. For the analysis of events, the time of the visit analysis windows can be configured, and the time of the gap between the so-called visits is (a concept analogous to the sessions on a website, but applicable to offline and online). The purpose of the analysis window is to decide if an Accepted event for the same OOID extends the visit or visit time of the same visitor. The purpose of the gap between visits is to distinguish different visits by the same visitor, considering that long periods of inactivity are due to different reasons or interests in visiting a physical or digital space. In an online analysis, the gap between visits is, in general, greater than the gap between sessions, that is, the inactivity time to consider that a new session of the same visitor begins. So the analysis of events includes configuring: a time of the visit analysis windows, where an analysis window includes a decision on whether an Accepted event for the same OOID extends the visit or visit time of the same visitor, and a time between visits , where said time is defined as elapsed between visits by the same visitor.
[0331] Normally the analysis window is less than the gap and it is less than a full day. After the time of the gap between visits is, the events are part of a new visit. After the visit or session gap, only the approved or unified events start the period of the analysis window. The valid, homologated, unified or accepted events received within the period of the analysis window would be grouped in the same visit, and therefore they are associated with the same visitor, and therefore with the same visit. Accepted events allow to extend the time of presence of a visit from the same visitor, and therefore also extend the presence of a visit.
[0333] With this method, visits will be dynamically extended as more events arrive within certain periods of time, thus obtaining the presence times of a visit in a given area, and online or offline behavior analysis could be carried out in real time. considering with the data of events received previously, and analysis not in real time with the data of a whole day or a month.
[0335] From the visits generated by the same visitor in the behavior analysis module in some implementations, many other functions and computations could be carried out, among others:
[0336] - They could establish criteria to validate detections. Among others, if the same visitor is offline in two geographically very remote areas.
[0337] - Analysis of average presence times.
[0338] - Evolution of visitors.
[0339] - Flows between various areas or online sites.
[0340] - Visits to a physical site that simultaneously or previously use the App or Web.
[0342] A field of application of specific interest for the implementation of the object of the invention is that in which the method described here is complemented with a manager of profiles, campaigns and results like the one shown in figure 9.4 where the interaction between components is observed. minus the following functions that provide the following functionalities:
[0343] A profile manager, which has among other tasks, calculate profiles or groups of users that should receive messages from the server or by proximity when detected by the node (101), based on certain criteria of segmentation or grouping of behavior, or You can also import / load the OOIDs of the UTs (102) from an external behavior analysis platform. From the events of Node (101) and the SDKs (104,105), the results of visitors and visits of the behavior system, and the rules entered in the campaign manager, the profile management system could calculate or compute which UTs (102) have the same cross-online and offline behavior profile, as well as any other marketing indicator such as a key performance indicator (KPI) that is considered of interest from these data, an example of a KPI can be the number of times on average that visitors with a family profile repeat their visit in a month. For example, a profile that we could call family type would be those devices that yesterday generated a visit to the website of a children's store in the shopping center, today they have opened the shopping center's APP to visit the movie billboard looking for a children's movie and they have also been detected by a node with a visiting presence of more than 5 minutes in the playground of the shopping center. Another example of cross-profile definition online and offline would be those who usually arrive at the office more than 10 minutes before the check-in time and have ever used the company's corporate APP to reserve meeting rooms. In the definition of the profile, the responses to the messages received can be included, for example a profile of employees in active training would be those employees who, when they receive messages inviting them to attend face-to-face courses, finally go to the classroom where said face-to-face course is held.
[0345] A system for triggering Messages by physical or digital proximity, based on the fact that when a device is detected through a Node (101) event in addition to generating a valid visit and homologated in real time by the behavior system, at this moment It is checked whether the OOID is included in an active profile and an active campaign, and a message is launched immediately through the campaign manager so that it reaches the user terminal (102) in real time through any of the available channels . This system could, among other functions, launch the messages to the UTs (102) programmed at the right time according to the information programmed in the campaign manager when receiving events from Node (101), Virtual Node (103) or SDKs (104,105 ) among other trigger events. That is, by proximity or visit to a physical site or a digital site.
[0346] Available online channels are all those that allow direct delivery to the user terminal (102) without the need for the user terminal (102) to previously request the message (that is, push type). For this, identifiers are available for communication ( tokens ) of each user terminal (102). Among others the channels are chosen from among: Push Notifications APP, Email, SMS, Push Notifications Web] or Push Notifications of browser. To send messages to the UTs (102), the Homologated or Non-Homologated OOIDs can be linked to each User entity (that is, the entity that stores said communication tokens and other personal data) in the server Node (103). Although a user terminal (102) does not have an approved OOID, it can receive messages from the server Node (103), but it would need the approved and validated OOID to push messages by proximity to the node (101).
[0348] The campaign manager, among other tasks, could generate or upload the content and message formats for the different channels chosen, as well as dates, areas, online sites, and any other useful variable for defining the campaign prior to its communication. It is expected to launch the campaigns and messages at the time programmed in the campaign manager, the messages to the programmed UTs (102). That is, by time and profile; It is also planned to import campaigns and messages from third parties through webservices or other procedures, to complete the functionality of the campaign manager.
[0350] The results manager, among other tasks, collects the confirmation information in sending messages from the proxies of each channel, the responses associated with the digital spaces that have been used in the communication (filling in the personal data form, surveys, subscriptions, etc ...), as well as its behavior in the physical and digital space after sending coupons, offers, information, surveys, other ways of suggesting visiting physical or digital sites, etc ... Therefore, it would be able to calculate, for example How many users who have received an offer by email on Friday afternoon, have been detected in the supermarket on Saturday morning.
[0352] Based on the information received from the result of the message, the information in the campaign manager can be updated. The results manager, in addition to reporting efficacy data, can act as a feedback loop to modify profiles and campaigns in real time, achieving dynamic optimization based on user response Thanks to the above functionalities, the system makes it possible to carry out what is known as remarketing but offline, which consists of sending a message to the user terminal (102) by proximity or offline presence, previously knowing their tastes or interests through digital behavior analyzed, for example in APPs or WEB sites that have the SDK integrated, or through the physical behavior analyzed in areas where there are nodes, and even based on responses to previously sent communications.
权利要求:
Claims (15)
[1]
1. Unique identification system of user equipment (102) capable of executing mobile applications, a system characterized in that the user equipment (102) comprises:
to. an APP SDK (104) for mobile applications, and
b. a web browser that in turn integrates a web SDK (105); and
because the system comprises interconnected a series of nodes (101) that are devices with processing capacity equipped with wireless communication means, where at least one of said nodes (101) is configured to listen and process information from radio signals in different frequency bands to determine the presence and identify the user equipment (102)).
[2]
2. Unique identification system for user equipment (102) capable of executing mobile applications, a system characterized in that it additionally comprises a server node (103) configured to analyze and propagate user equipment identifiers (102)).
[3]
3. Unique identification method of user equipment (102) characterized in that it comprises, by means of a node (101) with process capacity and equipped with wireless communication means adapted for listening and analyzing radio signals, listening and analyzing radio signals to determine the presence of at least one user equipment (102) in a physical area in which the node (101) is located.
[4]
4. Method according to claim 3 characterized in that the analysis carried out by the node (101) comprises demodulating and decoding the signal.
[5]
5. Method according to claim 2, characterized in that the detection of the presence of a user equipment (102) in a physical area is carried out by analyzing received frames.
[6]
6. Method according to claim 2, characterized in that the identification comprises a generation of at least one identifier (OOID) of an incremental and distributed type, based on a combination of signatures that come from the analysis in real time and historical events generated by the user equipment (102).
[7]
7. Method according to any one of claims 1 to 6, characterized in that it additionally comprises implementing a system for triggering Messages by physical or digital proximity, which comprises detecting:
to. a device is detected through a Node (101) event,
b. generate a valid and approved visit in real time,
c. check if the OOID is included in at least one of: an active profile and an active campaign, and
d. launching a message so that user equipment (102) (102) reaches it in real time through any of the available channels.
[8]
8. Method according to any one of claims 1 to 7, characterized in that it additionally comprises implementing privacy in the location and identification from third parties of the user equipment (102) that are in the physical space of scope of the Node (101), where the node (101) generates in real time or execution frames of discovery of the WLAN or BT networks, by the user equipment (102), using for this:
to. the same media access layer addresses of user equipment 102 recently listened to, or
b. the same addresses of the media access layer of the user equipment (102)) listened to by other nodes (101)
that have been received by the propagation process, and also generate them randomly with different common patterns similar to those received.
[9]
9. Method according to any one of claims 1 to 8, characterized in that it additionally comprises calculating a count of visitors and visits where said calculation in turn comprises:
to. receiving and registering an event from the server node (103) each time it is received, b. analyze said event taking into account the information of previous events available, during a period of time,
c. get different indicators for different time periods
[10]
10. Method according to claim 9, where the event analysis comprises configuring: to. time of the visit analysis windows, where an analysis window comprises a decision on whether an Accepted event for the same OOID extends the visit or visit time of the same visitor, and b. time between visits, where said time is defined as elapsed between visits by the same visitor.
[11]
Method according to claim 6, characterized in that it comprises managing the propagation of the identifier (OOID) of the user equipment (102) making said identifier identifier (OOID) available when using the user equipment (102) to navigate to web pages through the WEB SDK (105), when using APPs with the APP SDK (104) and entering physical areas within a coverage area of the nodes (101).
[12]
12. Method according to claim 6 characterized in that it comprises homologizing the identifier (OOID) of the APP SDK (104) or the identifier (OOID) of the WEB SDK (105) in those user equipment (102) that do not allow access to the address of the media access layer by software.
[13]
13. Method according to claim 6 where the medium access layer that the user equipment (102) emits by radio frequency and is detected by the nodes (101) has a randomized address.
[14]
Method according to any one of claims 1 to 8, characterized in that it additionally comprises calculating a count of visitors and offline, coming from the detection in the physical space within the coverage area of the Node (101), such as online, visits through browsing websites and using apps, where said calculation includes:
to. receive and record an event from the server node (103) each time it is received b. analyze said event taking into account the information of previous events available, during a period of time, and
c. get different indicators for different time periods
[15]
15. Method according to claim 11 where the analysis of both offline events, originating from the detection in the physical space within the coverage area of the Node (101), such as online, visits through web browsing and use of apps, includes configuring:
to. time of the visit analysis windows, where an analysis window comprises a decision on whether an Accepted event for the same OOID extends the visit or visit time of the same visitor, and
b. time between visits, where said time is defined as elapsed between visits by the same visitor.
类似技术:
公开号 | 公开日 | 专利标题
KR102098428B1|2020-04-07|Group association based on network determined location
US10152888B1|2018-12-11|Wireless transmission system to determine parking lot occupancy
CN104113861B|2018-03-02|For managing the method and system of the exchange in wireless network
Frank et al.2008|The sensor internet at work: Locating everyday items using mobile phones
US20130217333A1|2013-08-22|Determining rewards based on proximity of devices using short-range wireless broadcasts
US8989094B2|2015-03-24|Systems and methods for generating and displaying application information on a wireless station
US10972888B2|2021-04-06|IOT devices based messaging systems and methods
JP5389945B2|2014-01-15|Tracking system and method for tracking the position of a device
Hekmati et al.2021|CONTAIN: Privacy-oriented contact tracing protocols for epidemics
US20180367946A1|2018-12-20|IOT Messaging Communications Systems and Methods
Trivedi et al.2020|Digital contact tracing: technologies, shortcomings, and the path forward
Kravets et al.2015|For your eyes only
US10462609B1|2019-10-29|Systems and methods for tracking a person
WO2013163338A2|2013-10-31|Determining rewards based on proximity of devices using short-range wireless broadcasts
ES2855199A1|2021-09-23|System and method for unique identification of electronic devices
US10292037B1|2019-05-14|Mobile communication device automated home location register | assignment adaptation
Choi et al.2016|Location based authentication scheme using BLE for high performance digital content management system
Mndebele et al.2017|IoT based Proximity Marketing.
Gong et al.2018|LBSLAB: a user data collection system in mobile environments
Delzanno et al.2018|Physical Web for Smart Campus Management.
Bonné2017|Assessing and improving security and privacy for smartphone users
Ribeiro2016|Human mobility tracking through passive wi-fi: a case study of Madeira Island
US9762398B2|2017-09-12|Application-based toll-free data service
Champion2017|Unobtrusive, Pervasive, and Cost-Effective Communications with Mobile Devices
Waltari2020|Privacy-Aware Opportunistic Wi-Fi
同族专利:
公开号 | 公开日
WO2019115842A1|2019-06-20|
引用文献:
公开号 | 申请日 | 公开日 | 申请人 | 专利标题

US7961724B2|2005-03-18|2011-06-14|Qualcomm Incorporated|Dynamic media access control address assignment|
US20140244386A1|2013-02-26|2014-08-28|Facebook, Inc.|Targeting advertisements to logged out users of an online system|
US9015062B2|2013-06-20|2015-04-21|Aol Advertising Inc.|Systems and methods for cross-browser advertising ID synchronization|
US9590950B2|2014-04-18|2017-03-07|Locality Systems Inc.|Source based anonymity and segmentation for visitors|
US20150324635A1|2014-04-30|2015-11-12|Eye Stalks Corporation Dba Bay Sensors|Methods, systems, and apparatuses for visitor monitoring|
US20160225009A1|2015-01-29|2016-08-04|Yext, Inc.|Permitting a business with physical locations to connect with their customers on their mobile devices |
TWI640941B|2015-11-18|2018-11-11|立創智能股份有限公司|System for pushing advertisement and message|
法律状态:
2021-09-23| BA2A| Patent application published|Ref document number: 2855199 Country of ref document: ES Kind code of ref document: A1 Effective date: 20210923 |
优先权:
申请号 | 申请日 | 专利标题
PCT/ES2017/070809|WO2019115842A1|2017-12-12|2017-12-12|System and method for unique identification of electronic devices|
[返回顶部]